Weird Atom Init Issues VS. One Lizard #2709
Conversation
|
I somehow fixed it which is wild, because I'm a total dumbass. NSV13/code/controllers/subsystem/atoms.dm Line 29 in 10bf6e3 ^^ SOMEHOW, calling that MANUALLY with the Advanced ProcCall verb fixes it entirely, for the entire round. Anyways, somethings breaking but calling that seemed to fix it, at least as a temporary in game solution. And it works which is super cool i guess? |
Sure, lets call |
( : |
|
I did test the changes of the pull request myself and it does seem to fix the issue. Hopefully I won't have to manually crank the ss13 machine like before, I don't think the crew liked the issues that came from that. |
Neat! I've never actually had that issue trigger on my own local so I've mostly been operating off likely related janky things. Probably was the Sabre loading then.. |
Proc is on the controller already so no need for that.
DeltaFire15
changed the title
About The Pull Request
Sooo we have been having some very fun atom init issues popping up concerningly often, and given it tends to fix itself for a single tick (aswell as all only partially uninitialized atoms) if someone buys a shuttle / docks to an asteroid, my assumption is it has something to do with something SSmapping related. (Sabres?)
This messes with some components that touch this, namely some overmap z treadmill handling that was super cursed (still is, but a bit cleaner :) ), and ship interior z loading which was not only very cursed but also caused SSatoms to yell occassionally when multiple things started to load their interiors in a short timeframe.
Treadmills use some slightly more proper z initialization (instead of using ++world.maxz for.. their names??), while interior initialization is now handled by a queue system that sends signals when it's done loading. (Notably, only for asteroids and ships using
instance_interior(), boarding map loading (ai_load_interior()) remains unchanged.)As should be seen by the tag at the top, please only TM this for now, if at all. This might have consequences I am not quite aware of yet, since I'm messing with very complex things in this PR.
I'm not sure if this'll actually make the weird init issues stop, but it's my shot at them for the moment. We'll see if they still occur with this.
(According to someone in the comments this does resolve the issue, which I've never been able to trigger personally, so thats good).
Potentially fixes #2397
Why It's Good For The Game
I can't express my distaste for Atom Init partially breaking in enough words.
Testing Photographs and Procedure
Only partially tested for the moment, and fairly difficult to in-depth test too. Might ignite things.
Changelog
🆑
code: Ship interior loading now uses a queue system (for virtual z using things like Sabres & Asteroids)
code: Some overmap z generation handling is ever so slightly cleaner now.
fix: Should resolve certain atom init issues (that manifested as broken sparks, among many other things).
/:cl: